When a Jms session is transacted and a message gets rolled back, the JMSRedelivered flag is set on the message. Developers can configure Mule to use this to attempt message redelivery for a component by setting the maxRedelivery property on the JmsConnector. Setting this property will tell the connector to retry X number of times to redeliver the message before throwing a MessageRedeliveredException. The exception strategy on the connector can then be used to forward the message to a Dead Letter Queue (DLQ). Below shows an example JmsConnector configuration using ActiveMQ, see Configuring Jms for examples of other Jms server configurations.

<connector name="JMSConnector" className="org.mule.providers.jms.JmsConnector">
    <properties>
        <property name="acknowledgeMode" value="1"/>
        <property name="connectionFactoryJndiName" value="ConnectionFactory"/>
        <property name="jndiInitialFactory" 
            value="org.codehaus.activemq.jndi.ActiveMQInitialContextFactory"/>
        <property name="specification" value="1.1"/>
        <!-- how many times to try and deliver a redelivered message -->
        <property name="maxRedelivery" value="2"/>
    </properties>
        
    <exception-strategy className="org.mule.impl.DefaultExceptionStrategy">
        <endpoint address="jms://DLQ">
            <transaction action="JOIN_IF_POSSIBLE"/>
        </endpoint>
    </exception-strategy>
</connector>

This configuration will allow the message to be delivered 3 times; The first time the message is received plus 2 redeliveries. Then the exception strategy on the connector will get invoked. Notice that the exception strategy endpoint has a transaction element which defines JOIN_IF_POSSIBLE. This tells Mule if there is a JMS transaction in progress to include writing to the DLQ destination in the same transaction.